bump rain-deploy 0.1.10 -> 0.1.11 - #30

rain-deploy 0.1.11 has been published; this repo pinned 0.1.10.

Not a version-number change. 0.1.11 is breaking in two ways this repo had to
absorb.

rain-lib-memkv is a new transitive dependency. 0.1.11's
RainDeployVerifySnapshotBase imports LibMemoryKV, and recursive_deps = false
means a consumer lists its transitives itself, so the build failed on an
unresolvable import until rain-lib-memkv 0.2.0 was added here.

writeSnapshot gained a root parameter, so the five-argument call in
script/Build.sol no longer resolved. It now passes recordRoot() — which
regenerateLibs in the same file already passes, for the same reason: the record
root is the tree the snapshot is written under, and threading it makes the two
calls agree.

The candidate pins do not move

DecimalFloat stays at 0xEc632ea4… and LogTables at 0xc51a1425….
rain-deploy is build and verification machinery, not part of either creation
code. Confirmed by regenerating both candidates and diffing before/after, not
inferred from which files the bump touched.

QA

• Discriminating tests: the compiler and the repo's own artifact guards, both
  of which failed on base and pass now. The build failed twice with distinct
  errors — an unresolvable rain-lib-memkv import, then
  Member "writeSnapshot" not found ... after argument-dependent lookup — and
  each names exactly the breaking change it corresponds to. The candidate guard
  passes unchanged, which is the discriminating result for the pins: had
  rain-deploy been part of either creation code, regeneration would have moved
  an address and the committed snapshot would now differ.
• Mutations applied: n/a. The diff is a version pin, a new pin, mechanical
  import-path rewrites, and one added argument. The added argument is the only
  hand-written change and it does not compile wrong — an absent or wrongly-typed
  root is a compile error, and a different root would fail the candidate guard
  by writing the snapshot somewhere the guard does not read.
• Oracle: for the pins, the Zoltu factory via script/Build.sol, run before
  and after. For the API change, 0.1.11's own source: writeSnapshot's two
  overloads were read directly rather than guessed from the error, and
  recordRoot() was taken from BuildScript rather than invented.
• Category check: the category is "this repo pins a stale rain-deploy".
  Covered: the pin, the new transitive it requires, the one call whose signature
  moved, and confirmation that the deployed addresses are untouched. Nothing else
  changes.

Verification

42 suites, 74 passing. Every failure is environment rather than code:

• the *_RPC_URL fork tests, with no env vars locally;
• the DecimalFloat not deployed prod checks, which wait on the new address from
  bump rain-math-float 0.2.1 -> 0.2.4 #29 being deployed;
• one new 0.1.11 check, testSupportedNetworksAreFullyConfigured, reverting
  EtherscanEntryUnresolvable("arbitrum") because
  ${CI_DEPLOY_ARBITRUM_ETHERSCAN_API_KEY} is unset here.

That last one is new machinery, so I checked the config it guards rather than
assuming: [rpc_endpoints] and [etherscan] both name the same 9 networks as
supportedNetworks(), key by key. The revert is the unresolved placeholder, not a
missing entry.

forge lint -D warnings and forge fmt --check both exit 0.

🤖 Generated with Claude Code